Wir fangen mal trotzdem an. Ich begrüße euch dann mal recht herzlich.

Wo soll es weitergehen? Da wo wir letzte Woche aufgehört haben, beim Range Target Address Cache.

Ihr erinnert euch, wir speichern für die Sprungvorhersage letztendlich drei Infos.

Einmal die Info, um welche Sprunginstruktion geht es eigentlich.

Also nicht die Instruktion wird gespeichert, sondern wo die Instruktion steht.

Eine Zieladresse, wenn wir dann springen wollen, damit wir nicht mühsam noch irgendeine Alu bemühen müssen.

Das wird einfach schließlich zu lange dauern.

Für die Sprung Vorhersage müssen wir irgendwie so ein bisschen Historie haben, sprich wir brauchen solche Prediction Bits.

Das war jetzt die letzte Folie vom Donnerstag, wo wir gesagt haben, wir haben ja nur eine Vorhersage.

Das ist nicht die Wahrheit, nicht notwendigerweise.

Das soll heißen, es kann mal in die Hose gehen mit der Vorhersage.

Wir wollen es noch angucken, dass das möglichst selten in die Hose geht, aber es kann in die Hose gehen.

Das zweite, wenn es dann mal in die Hose gegangen ist, was machen wir dann?

Dann müssen wir irgendwie erstens natürlich die Vorhersage fürs nächste Mal fixen, wenn es geht.

Das soll heißen, wir müssen unseren Brandes Target Address Cache updaten.

Also jetzt nicht die Zieladresse, die wird hoffentlich schon richtig gewesen sein.

Aber natürlich die Vorhersage Bits.

Das ist jetzt der etwas unangenehme Teil.

Wir müssen alles, was wir seit dem falschen Sprung gemacht haben, in die Tonne hauen.

Ja, jetzt hatten wir, ich mach jetzt nochmal hin, eine Pipeline, uns bisher schon ausgedacht,

irgendwie so Instruktion holen, Adressoperanten holen, Adresse rechnen.

Dann hatten wir unseren Operanten holen bzw. Load.

Wir hatten unsere Execute Stage und wir hatten unser Write Back bzw. Store.

Ja, wann wissen wir dann wirklich, wo wir hätten weitermachen sollen?

Wir wissen es, wenn wir die Sprunginstruktion geholt haben,

wenn wir so ein bisschen hier durchgeklackert sind und letztendlich da berechnet haben,

wo es dann eigentlich hätte hingehen sollen.

Das ginge früher.

Da schüttelt jemand den Kopf, warum nicht?

Also davor läuft normalerweise ein Compare vor dem bedingten Sprung.

Das Compare ist dann typischerweise eine Subtraktion.

Ja und erst wenn die Subtraktion da durch ist, weiß ich überhaupt, ob ich springen soll oder nicht.

Sprich auch erst wenn die Sprunginstruktion beim Execute angekommen ist, wissen wir, ob wir hüpfen wollen oder nicht.

Ja, soll heißen, alles was davor steht, mich.

Was hat denn das für Auswirkungen?

Das ist schon mal unangenehm.

Also gut, hier haben wir jetzt eine 6-stufige Pipeline, aber wenn jemand gemunkelt hat, Intel 40 Stufen,

wenn wir dann schon mal 40 Instruktionen wegschmeißen, wollen wir nicht unbedingt.

Wir haben gesagt, jeder 5. Befehl ist ein Sprung.

Wenn wir da so ein paar von falsch machen, dann schmeißen wir mehr weg als wir überhaupt ausführen.

Zweiter Punkt, man kommt nicht so leicht drauf, aber ich sag mal,

alles was ich da wegschmeiße, darf natürlich in keinster Weise irgendeine Art von Auswirkungen gehabt haben.

Ich behaupte aber, da kann was Auswirkungen haben.

Genau, also, dass ich eine Instruktion geholt habe, die ich wegschmeiß, das sollte nichts ausmachen.

Es gibt zwar auch Leute, die führen Code im Videospiel aus und solche Geschichten, aber ok, wer das macht hat selber Schuld.

Dass ich Adressoperanten geholt habe, das sind Registerwerte in der CPU, wenn ich die wieder wegschmeiß, sind sie halt wieder weg, kein Problem.

Dass ich mühsam eine Adresse berechnet habe, die ich wieder wegschmeiß, macht nichts.

Dass ich aus dem Speicher was geholt habe, das kann ich auch wieder wegschmeißen.

Aber, wurde schon richtig gesagt, es gibt natürlich auch Memorymapped I.O. Geschichten.

Wenn ich jetzt von der seriellen Schnittstelle mir einen Byte abhole, was ich dann hinterher wegschmeiße, kann ich zwar gern tun,